Description

• Feature
• Bug Fix
• Code Refactor
• Documentation

Starting a print on an unloaded machine left Happy-Hare running a job that had already been cancelled. RF50-Klipper's PRINT_START raised "Machine is unloaded", virtual_sdcard ran CANCEL_PRINT, and Happy-Hare's deferred auto-start re-opened the job (#358 closes that job afterwards). This PR runs the macro's unloaded check in BlocksScreen before the print is sent, so the start never happens and the screen says why.

Changes

• amu manager: print_start_refusal() returns why PRINT_START would refuse, using the macro's exact test (sensors.toolhead == False or sensors.mmu_pre_gate == False); a missing or disabled (None) sensor passes, as in the macro
• print tab: start_print runs that check before JobStatusWidget.on_print_start; a refusal is logged and shown through a new notify signal, wired to the notification page
• print tab: takes an optional amu_manager; without one (no AMU) prints start as before
• main window: the cancel page's reprint goes through start_print too, so it gets the same check as a fresh print

Motivation

• A refused PRINT_START is not a clean refusal: the on_error CANCEL_PRINT races Happy-Hare's deferred MMU_PRINT_START AUTOMATIC=1, which re-opens the job with the gear synced, FlowGuard armed and the tensioner in print mode
• The check copies config/print_start.cfg instead of reading HH's gate map, so BlocksScreen refuses exactly the starts the macro would refuse

Tests

• New: TestPrintStartRefusal (no state, loaded/missing/disabled sensors, toolhead empty, gate empty, klippy disconnect drops the refusal), tests/widgets/test_print_start_guard_unit.py (start without AMU or refusal, refusal blocks and notifies)

Future work

• Report the deferred auto-start race upstream to Happy-Hare
• Keep print_start_refusal in step with print_start.cfg if the macro's condition changes